Code review

Found 2 issues:

1. useCallback is not allowed per AGENTS.md CRITICAL RULES ("NEVER: useMemo, useCallback — React Compiler handles optimization"). doAccept can be a plain async function inside the component, the compiler will take care of referential stability.

2. isInvitationPage in auth.config.ts is too broad. It uses startsWith("/invitation"), which lets any path under /invitation/* bypass auth in the NextAuth layer. proxy.ts was already narrowed to /invitation/accept only (commit "restrict public route to /invitation/accept only"), but auth.config.ts was missed. Should be:

const isInvitationPage = nextUrl.pathname.startsWith("/invitation/accept");

Overall the architecture is clean, nice work splitting the (guest-only) layout and the backward-compat redirect with the action=signup escape hatch. Just these two to tidy up 👍

Seven things to address. The first three I'd consider blocking, the rest are smaller but worth doing in the same PR.

1. /sign-in button in the 404 error state is a dead end for authenticated users. When the API returns 404 (wrong-email case), the user is logged in with the wrong account and clicks "Go to Sign In" — but /sign-in now lives under (guest-only) layout, which redirects authenticated users back to /. They land on the wrong-account dashboard with no recovery path. Fix: gate on the 404 case and sign out before redirect: await signOut({ redirect: false }); router.push("/sign-in?callbackUrl=" + encodeURIComponent(callbackPath)).

2. Error mapping by HTTP status is fragile. Switching on 400/404/410 assumes those codes only ever mean "already used", "wrong email", "expired" — but the API will inevitably return 400 for malformed tokens and 404 for nonexistent invitations too, both of which will surface the wrong message. handleApiResponse already exposes errors[0] from the JSON:API body — switch on result.errors?.[0]?.code and keep status only as a fallback. If the API doesn't have stable error codes yet, open a follow-up.

3. E2E coverage is too thin for an auth flow refactor. The new test only validates query param preservation in callbackUrl. Missing: authenticated happy path (token + auth → accept → dashboard), unauthenticated choose → sign-in → back to accept, the three error states (410/400/404), the backward-compat /sign-up?invitation_token= redirect, and the (guest-only) redirect of authenticated users. ui/CLAUDE.md marks tdd as mandatory for refactors — add at least the four flow tests or link a follow-up ticket here before merge.

4. acceptInvitation server action accepts unvalidated input. The token comes from a URL search param (attacker-controllable) and goes straight to JSON.stringify without Zod validation. The convention in ui/CLAUDE.md is all inputs validated with Zod. Add z.object({ token: z.string().min(1).max(500) }) at the entry of the action.

5. action=signup is a magic string contract between proxy.ts and the client. The bypass works because both files happen to use the literal "signup", but there's no shared definition — six months from now someone refactors the middleware, sees the unexplained action param, and removes it, silently breaking the smart-router-to-sign-up path. Extract to ui/lib/invitation-routing.ts as export const INVITATION_SIGNUP_ACTION = "signup" and import on both sides.

6. kind: "loading" is dead state. The useState lazy initializer sets it for the auth+token case, but the useEffect immediately overwrites it with kind: "accepting" — both render the same spinner. Drop loading from the union and start in accepting. Better still: move the auth+token decision into page.tsx (server component) so the happy path doesn't flash a client loading state at all.

7. setState({ kind: "success" }) + router.push("/") race. The success UI may or may not flash for a tick depending on timing. Either drop the success state and navigate immediately, or keep it visible with an 800–1000ms delay before navigation.

What's good: the (guest-only) route group is the right Next.js 15 pattern, the discriminated union on state instead of boolean flags, the backward-compat in proxy.ts thinking about users with old links in their inbox, and the callbackUrl + nextUrl.search fix is the correct shape with an E2E test backing it.

Re-reviewed after f742f6c. Five of seven items addressed cleanly: the sign-out dead end is fixed with needsSignOut + handleSignOutAndRedirect, Zod validation is in, magic strings extracted to invitation-routing.ts with a good JSDoc, and both dead states (loading + success) are gone — the union is now just no-token | accepting | error | choose.

Two remaining items are acceptable as follow-ups:

1. Error mapping still switches on HTTP status. When the API adds stable error codes to the JSON:API errors array, switch to result.errors?.[0]?.code. Until then the current mapping works, just fragile.

2. E2E coverage. The auth flow refactor has one new test (query param preservation) but no coverage of the smart router states, backward-compat redirect, or guest-only layout redirect. Worth a follow-up PR or ticket to close the TDD gap before the next round of changes to this flow.

Clean iteration — good turnaround.